This TOC was quite outdated, and I realized it'll always be problematic. This doc isn't so long now that API Reference is its own thing, so I ditched the TOC.

This is something I noticed in Storybook; It's kind of a bummer :( and makes me think that wrapperless mode will likely cause more trouble than it's worth... but I figure we'll see. If we get a ton of confusing issues, maybe we can add a check that console.warns when the parent DOM element isn't configured correctly.

since we already have the dom node, those styles could be overwritten after findDOMNode:

  findDOMContainer = () => {
    // eslint-disable-next-line react/no-find-dom-node
    const domNode = ReactDOM.findDOMNode(this);
    const parentNode = domNode && domNode.parentNode;

    // This ought to be impossible, but handling it for Flow's sake.
    if (!parentNode || !(parentNode instanceof HTMLElement)) {
      return;
    }

    // Make sure parentNode has position relative and no padding
    parentNode.style.position = 'relative';
    parentNode.style.padding = 0;

    this.parentData.domNode = parentNode;
  };

should be mentioned in the docs though.

parentNode.style.position = 'relative';

We can do that only if window.getComputedStyle(parentNode) === 'static')
And we can't change the padding as it would break the layout

Yeah, so I thought about applying a "default" relative position if it isn't set to something other than static, but it feels a bit like it crosses a line; we'd be mutating nodes outside of Flip Move's control. It could cause confusion for users if they have absolutely-positioned things down-tree.

So either we apply position: relative, which fixes FlipMove but breaks their layout, or we do nothing, and it breaks enter/exit animations. The latter is clearly a FlipMove issue, and so they'll come here and we can advise them... but the former might appear to them as a CSS issue / they won't understand why things are broken, why a random position: relative is being applied to their div...

Maybe we can apply relative positioning if it's static, and also console.warn to let them know what's happening? But, if the user doesn't need enter/leave animations, they don't need this position: relative, and so the warning would just be console spam.

That said, it's really rare that position: static is actually desirable (I've seen a trend where people just add a * { position: relative } global CSS rule), so I think it's probably best to optimize for the common usecase.

Gonna do it in a subsequent PR to make reviews easier, but I'll apply @Hypnosphi's static check, and issue a console.warn when the change is necessary.

I mentioned this in #202, and didn't see any strong opinions; my preference is that we use null over false, since it feels more "pure" semantically.

If y'all think there's value in also supporting false (or if there's an argument I haven't thought of for why false makes more sense?), happy to update :)

I prefer null

Argh, Prettier updated all the formatting here, adding trailing commas and single-quotes.

@Hypnosphi does this matter?

Also, I renamed this file from 2.9 to 2.10, as the version will change. Should there be a flow-typed file for every version?

yeah, pretty sure there should be. we don't want to allow null as a value on versions lower than 2.10.x

you can use wildcards in the name to span multiple versions though, like we're currently doing with the patch version.

does this matter?

If it doesn't for you, you shouldn't use prettier =) And I believe, trailing commas are one of the few things that are configurable

yeah, pretty sure there should be. we don't want to allow null as a value on versions lower than 2.10.x

Yep, makes sense, thanks!

If it doesn't for you, you shouldn't use prettier =) And I believe, trailing commas are one of the few things that are configurable

You misunderstand; I was asking specifically about flow-typed. Wanted to make sure there wasn't a different community convention for these type files (or, worse, third-party tools that don't understand trailing commas)

But yeah, sounds like it's a non-issue, so I'll go ahead.

Well we kinda introduce new API, so it requires an updated libdef

And I think we should disable eslint for flow-typed directory so that it’s easier to sync it with the version in flow-typed repo